GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Zonentransfer</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Zonentransfer</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p><b>Zonentransfer</b> bezeichnet beim <a href="Domain_Name_System" title="Domain Name System">Domain Name System</a> (DNS) die Übertragung von <a href="Zone_(DNS)" title="Zone (DNS)">Zonen</a> auf einen anderen Server. Dieses Verfahren wird AXFR (<i>Asynchronous Full Transfer Zone</i> oder <i>Asynchronous Xfer Full Range</i>) abgekürzt.

Da ein DNS-Ausfall für ein Unternehmen meist gravierende Folgen hat, werden die DNS-Daten – also die <a href="Zonendatei" title="Zonendatei">Zonendateien</a> – fast ausnahmslos identisch auf mehreren Nameservern gehalten. Bei Änderungen muss sichergestellt sein, dass alle Server den gleichen Datenbestand besitzen. Die Synchronisation zwischen den beteiligten Servern wird durch den <i>Zonentransfer</i> realisiert. Der Zonentransfer beinhaltet nicht nur das bloße Übertragen von Dateien oder Sätzen, sondern auch das Erkennen von Abweichungen in den Datenbeständen der beteiligten Server.

</p><p>Die originären Daten einer Zone liegen auf einem DNS-Server, der als <i>Primary Nameserver</i> (kurz: Primary) für diese Zone bezeichnet wird. Zur Erhöhung der Ausfallsicherheit, Realisierung einer einfachen <a href="Lastverteilung_per_DNS" title="Lastverteilung per DNS">Lastverteilung</a> oder um den Primary vor Angriffen zu schützen (siehe auch: <a href="Hidden_Primary" title="Hidden Primary">Hidden Primary</a>) werden in der Praxis in fast allen Fällen ein oder mehrere zusätzliche Server installiert, die als <i>Secondary Nameserver</i> (kurz: Secondary) für diese Zone bezeichnet werden. Bei einigen <a href="Top-Level-Domain" title="Top-Level-Domain">Top-Level-Domains</a> (z. B. <a href="DENIC" title="DENIC">de.</a>) ist es sogar Vorschrift, Zonendateien für die <a href="Second_Level_Domain" class="mw-redirect" title="Second Level Domain">Second Level Domains</a> auf mindestens zwei Servern zugänglich zu machen.

</p><p>Ein DNS-Server kann nicht pauschal als Primary oder Secondary bezeichnet werden. Diese Funktion ist stets in Bezug auf eine <a href="Zone_(DNS)" title="Zone (DNS)">Zone</a> zu betrachten. So kann ein DNS-Server Primary für eine Zone und Secondary für eine andere Zone sein.

</p><p>Die DNS-Informationen eines Primary und eines Secondary werden als qualitativ gleichwertig angesehen. Sowohl Primary als auch Secondary sind <i>autoritativ</i> für eine Zone, d. h. ihren Daten kann unbedingt vertraut werden (im Gegensatz dazu werden beispielsweise Daten aus DNS-Caches als <i>nicht-autoritativ</i> angesehen, da sie veraltet sein können).

</p><p>DNS-Einträge werden grundsätzlich nur auf dem Primary erzeugt, geändert oder gelöscht. Das kann durch manuelles Editieren der betreffenden Zonendatei oder automatisch durch <a href="Dynamisches_Update" class="mw-redirect" title="Dynamisches Update">dynamisches Update</a> aus einer Datenbank erfolgen. Eine Ausnahme bildet hier der DNS-Server von Microsoft. Bei diesem können in einer Active-Directory-integrierten Zone sowohl in der Primary als auch in der Secondary Zone Daten eingetragen werden.

</p><p>Ein DNS-Server, der als direkte Quelle für die Synchronisation einer Zonendatei dient, wird als <i>Master</i> bezeichnet. Einen DNS-Server, der die Zonendaten von einem Master bezieht, nennt man <i>Slave</i>. Ein Primary ist stets Master, während ein Secondary sowohl Slave als auch Master sein kann. Er ist Slave, falls er die Zonendaten von einem Master bezieht; er ist Master, falls er selbst als Quelle für weitere sekundäre Server dient. Diese Schachtelung von sekundären Servern wird häufig verwendet, um die Belastung des primären Servers durch den Zonentransfer zu vermindern.

</p><p>Dieses Verfahren wurde in der ursprünglichen DNS-Spezifikation eingeführt und erstmals mit dem DNS-Server BIND genutzt. Neben AXFR gibt es noch das neuere <a href="Inkrementeller_Zonentransfer" title="Inkrementeller Zonentransfer">IXFR</a> (RFC 1995<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>), das lediglich geänderte Records überträgt und nicht die gesamte Zone.

Für die Synchronisation zwischen Master und Slave existieren zwei Methoden:

</p>

<div class="mw-heading mw-heading2"><h2 id="Notify-Verfahren">Notify-Verfahren</h2></div>

<p>Der Master benachrichtigt alle Slaves einer Zone, sobald sich in der Zone etwas geändert hat. Der Slave fordert dann entweder die komplette Zone an oder – besser – per <a href="Inkrementeller_Zonentransfer" title="Inkrementeller Zonentransfer">inkrementellen Zonentransfer</a> nur die geänderten Resource-Records. Die Informationen, wer Slave ist, wird indirekt aus den <a href="NS_Resource_Record" title="NS Resource Record">NS Resource Records</a> einer Zone abgeleitet. Der Master ist im <a href="SOA_Resource_Record" title="SOA Resource Record">SOA Resource Record</a> aufgeführt. Alle anderen in NS-RRs aufgeführten Server gelten automatisch als Slave.

</p>

<div class="mw-heading mw-heading2"><h2 id="Slave-Hol-Verfahren">Slave-Hol-Verfahren</h2></div>

<p>Der Slave holt in bestimmten Abständen (der so genannten <i>Refresh Time</i>, die typischerweise eine Stunde beträgt) den <a href="SOA_Resource_Record" title="SOA Resource Record">SOA Resource Record</a> der betreffenden Zone vom Master und vergleicht die <i>Seriennummern</i>. Ist die Seriennummer des SOA-RRs des Masters größer als die des Slaves, stimmen die Datenbestände nicht mehr überein. Der Slave fordert dann entweder die komplette Zone an oder – besser – per inkrementellen Zonentransfer nur die geänderten Resource-Records.

Die maßgeblichen Parameter (z. B. Seriennummer und Refresh-Timer) befinden sich im SOA-RR. Der Master legt diese Werte fest und zwingt sie den Slaves auf.

</p><p>Das Notify-Verfahren ist dem Slave-Hol-Verfahren deutlich überlegen, da Änderungen schneller zu den Slaves übermittelt werden. Es ist heute Standard. Zum Zonentransfer wird grundsätzlich <a href="Transmission_Control_Protocol" title="Transmission Control Protocol">TCP</a> verwendet und nicht, wie bei DNS-Requests, <a href="User_Datagram_Protocol" title="User Datagram Protocol">UDP</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Sicherheit">Sicherheit</h2></div>

<p>Durch einen geheimen Schlüssel (bei <a href="BIND" title="BIND">BIND</a> <i>rndc-key</i> genannt) vergewissern sich die Server, dass sie wirklich mit ihrem Master/Slave verkehren.

</p>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1995" class="extiw external" title="rfc:1995">1995</a></span></i> – <i><span lang="en">Incremental Zone Transfer in DNS (IXFR)</span></i>. (englisch).</li>

<li><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc5936" class="extiw external" title="rfc:5936">5936</a></span></i> – <i><span lang="en">DNS Zone Transfer Protocol (AXFR)</span></i>. (englisch).</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1995" class="extiw external" title="rfc:1995">1995</a></span></i> – <i><span lang="en">Incremental Zone Transfer in DNS (IXFR)</span></i>. (englisch).</span>

</li>

</ol></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2023-06-20" href="https://de.wikipedia.org/wiki/?title=Zonentransfer&oldid=234785249">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>